Programmation

Les challenges de programmation peuvent être divisés en deux parties, les challenges de programmation proprement dits comme sur Valladolid et des problèmes plus légers sur la plupart des sites de challenges. Valladolid constitue une mine fantastique de problèmes sur lesquels se pencher. Mais il faut être conscient que la difficulté des problèmes peut considérablement varier de l'un à l'autre et que, lorsque votre réponse est inexacte ("WA" = wrong answer), il vous sera parfois difficile de comprendre pourquoi. Ayant réussi 900 de ces problèmes, je peux dire que c'est un vrai plaisir de passer 15 ou 20 minutes à en résoudre un, mais soumettre une solution pour le même problème et être gratifié de "WA" à répétition, peut être sacrément frustrant. Si vous partez de rien, alors choisissez des problèmes déjà fréquemment traités et avec un taux de succès élevé. Portez aussi toute votre attention sur les forums et les commentaires que les gens y font.

La plupart des challenges de prog ont tendance à se limiter à des tâches plutôt simples. La majorité ne demande qu'une ou deux choses : soit calculer quelque chose et obtenir une réponse (combien de fois trouve-t-on la chaîne "ABC" dans tel fichier texte), soit la page Web "x" va vous fournir des données avec lesquelles vous allez devoir faire quelque chose et retourner le résultat vers une page "y", en respectant une forme donnée, en tant de secondes.

Il est toujours intéressant de connaître un maximum de langages de programmation. Mais si vous êtes débutant et que vous apprenez votre premier langage, alors bon courage ! Personnellement, je pense que C est un bon langage à connaître bien qu'il ne soit pas vraiment fait pour les débutants. L'avantage, c'est qu'en connaissant C, il n'y a pas grand chose à ajouter pour apprendre PHP. C'est idéal pour les petits progs "à usage unique" qu'on écrit en dix minutes. Mais C, en revanche, n'est pas le langage le plus adapté aux problèmes de la deuxième catégorie ci-dessus. Pour ceux-ci, je ferais une des choses suivantes. Premièrement, utiliser Borland C++ Builder, ou un environnement RAD. Il n'est pas difficile de se faire un prog qui se connecte sur le Web. Mais comme bizarrement il est moins facile d'accéder au code source de la page retournée, vous aurez besoin de quelque chose comme ceci. Ou, deuxièmement, utiliser une combinaison de programmes y compris mon propre "pêcheur" de pages et des fichiers batch pour envoyer une requête vers une page et stocker le résultat dans un fichier, traiter l'info et récupérer le résultat. Ca sonne compliqué, mais ça n'est pas le cas. En fait, c'est plutôt un mode de pensée latérale dont on a besoin. Je suis certain que maintenant, des tas de gens vont se demander à quoi ça sert de faire ça puisqu'il suffit de pisser quelques lignes en PERL ou en PHP. Le résultat, c'est que chacun va faire un truc différent : un sondage récent sur un site a montré que chacun utilisait un langage de programmation différent pour attaquer un problème. Personnellement, je crache du code C à une vitesse étonnante et c'est pour ça que je pratique ainsi. Après 900 programmes pour Valladolid, j'écris le C plus vite que l'anglais :)

Si un site donné de challenges a dix problèmes de prog qui sont tous de la forme "connectez-vous à telle page Web, récupérez les données du problème, traitez les et retournez la réponse sur une autre page, il est évident que la bonne approche est de se constituer un squelette dans lequel on pourra insérer une section "Traitement du problème" propre à résoudre chaque challenge. Certaines personnes poussent à l'extrême cette logique de réutilisation. Quant à moi, j'ai quelques routines de base que je réutilise (la majorité pour traiter des problèmes de grands nombres entiers). A l'occasion, je vais réécrire un autre programme pour un autre usage mais j'écris vraiment un tas de choses ex nihilo. Dans le passé, j'ai passé beaucoup de temps à chercher sur le net des codes que j'aurais pu écrire moi-même... et j'y ai passé plus de temps que ça ne m'aurait pris à les écrire en partant de zéro.

La vérité au sujet des challenges de prog, c'est que j'ai souvent écrit des programmes plus gros et plus complexes pour résoudre d'autres épreuves sur les mêmes sites, comme de la crypto, ou pour craquer certains mots de passes. Si vous vous mettez sérieusement aux challenges, alors vous aurez vraiment besoin de coder pour faire tout un tas de choses et la plupart des niveaux de programmation ne présenteront pas de difficulté pour vous. Souvent, une petite partie du programme constituera plus un problème que le problème lui-même : par exemple, comment coder une requête POST dans tel ou tel langage ?

En écrivant tout ça, je me sens un peu obligé d'ajouter un programme et que vous puissiez en faire quelque chose. Et plutôt que de me rabattre sur quelque chose de similaire à un challenge quelconque (comme calculer la somme des carrés des nombres de 1 à 10000, ce qui prend moins d'une minute à faire dans Excel, environ vingt secondes dans Maple, ces deux progs représentant les deux choix évidents pour ce problème donné), je préfère traiter à la place quelque chose de plus utile. Au cas particulier, ce sera un prog de requête de page Web. Il y a quelque temps, sur le challenge "Aspect" (1) qui était en ligne, il y avait un jeu en temps réel dans lequel vous deviez attaquer d'autres joueurs et construire votre empire. Vous pouviez effectuer autant de mouvements que vous le souhaitiez. C'est ce programme que je vais évoquer ici (bien que je doive l'épurer un peu pour l'insérer ici), comme base d'un programme capable de jouer en automatique sur "Aspect".

Certains d'entre vous ne manqueront pas de remarquer que ce programme est très proche du SMTPsend que j'avais écrit : c'est à la base le même source que j'ai réécrit. Il vous faut donc une requête HTTP typique et le code source. Maintenant, entrez juste quelque chose du genre :

httpget -v www.fbi.gov request.txt

Et le programme va démarrer et faire son travail. Avec un peu de réflexion et de travail sur le texte retourné, vous pourriez utiliser ceci dans un bruteforceur, ce que je ne recommande pour aucun des challenges d'Electrica, car j'ai tenu compte de ça en écrivant les épreuves et ça prendrait une éternité de bruteforcer n'importe laquelle d'entre elles. De la même façon, je ne vous conseille pas de bruteforcer les autres challenges, à moins que ce ne soit spécifiquement exigé par l'épreuve.

Le code source devrait se suffire à lui même en guise d'explications. Rien ne vaut une requête HTTP et sa réponse, une conversation toute simple tout au long des lignes de "donne moi cette page" et "là voilà", comparé à SMTP qui est un peu plus compliqué. Une petite pause avant la fin sera bien utile, juste avant la fermeture de la connexion pour vous permettre de rechercher la balise </html>, si par exemple vous souhaitez coder un bot comme je l'ai fait. Pour aller au bout de certains challenges, vous devrez réussir à coder des fonctions pour traiter le texte retourné et générer une nouvelle réponse à renvoyer. Pour ça, il vous faudra ajouter toute la réponse dans un buffer, le parser, formuler et renvoyer cette seconde requête. Facile ! Vous pouvez envoyer à nouveau request.txt, en remplaçant la première ligne par votre réponse.

Tant qu'on y est, la meilleure manière de construire le premier request.txt, (notamment si le site utilise des cookies), c'est de le récupérer dans la fenêtre de log de Proxomitron. Mettez toutes les options sur off, récupérez une requête avec IE, coupez et collez les headers dans le fichier texte et c'est parti. Proxomitron est évoqué dans la page Internet de ce manuel :)

Si vous voulez réellement en apprendre davantage sur la programmation, je suis certain que vous avez déjà portévotre choix sur un langage et que vous trouverez plein de choses dessus. Donc, plutôt que d'attendre quelques ressources alternatives, pourquoi est-ce que vous ne passeriez pas un peu de temps à lire sur les algorithmes ? Le livre de Knuth couvre parfaitement le sujet. Je l'ai apprécié il y a quelques années pour son information sur la multiprécision arithmétique. "Introduction to Algorithms" est un gros bouquin très complet. Je m'y réfère souvent quand j'ai un problème sur ACM. Il est bien plus facile à lire que Knuth. Le livre de Herbert Schildts "Programming from the ground up" est extrêmement détaillé. Ma version est de 1998 mais il semble que la dernière date de 2000.